5.3.3 APPX Application Design Manual

+ Chapter 1-1: Overview of Application Design
+ Chapter 1-2: Getting Started
+ Chapter 1-3: Data Dictionary
+ Chapter 1-4: Understanding Process Design
+ Chapter 1-5: Interprocess Communication
+ Chapter 1-6: Customizing Your Application
+ Chapter 1-7: The Documentation Facility
+ Chapter 1-8: Application Design Tools
+ Chapter 2-1: Data Dictionary Overview
+ Chapter 2-2: Data Dictionary Concepts
+ Chapter 2-3: Domains
+ Chapter 2-4: Files and Fields
+ Chapter 2-5: Work Fields
+ Chapter 3-1: Overview of APPX Processes
+ Chapter 3-2: Getting Started
+ Chapter 3-3: Process Definition
+ Chapter 3-4: Menu Processes
+ Chapter 3-5: Job Processes
+ Chapter 3-6: Input Processes
+ Chapter 3-7: Output Processes
+ Chapter 3-8: Update Processes
+ Chapter 3-9: Query Processes
+ Chapter 3-10: Inquiry Processes
+ Chapter 3-11: Status Processes
+ Chapter 3-12: Subroutine Processes
+ Chapter 3-13: Table Processes
+ Chapter 3-14: Automatic and Optional Children
+ Chapter 3-15: Using the Image Editor
+ Chapter 3-16: Using GUI Features of the Image Editor
+ Chapter 3-17: Using Event Points
+ Chapter 4-1: ILF Integration
+ Chapter 4-2: True/False Status Indicators
+ Chapter 4-3: Specifying Statements
+ Chapter 4-4: The ILF Editor
+ Chapter 4-5: The Appx ILF Debugger
- Chapter 4-6: ILF Keyword Reference
+ Chapter 4-7: Predefined Fields
+ Chapter 4-8: Runtime Subroutine's and Predefined Processes
+ Chapter 4-9: Appx Chart Director API

Chapter 4-6: ILF Keyword Reference

COMMIT


The COMMIT statement causes an immediate commit of all changes made to the tables stored within an RDBMS. All record locks are forfeited.

  ?????   COMMIT 
  (1)

(1) T/F execution conditions

Using the Statement

The COMMIT MODE predefined field determines if and when APPX commits your changes automatically. It is initially set based on the Commit Mode specification from your process (in Additional Attributes) but can be modified. If you change COMMIT MODE, the change will take affect at the next COMMIT or ROLLBACK.

Based on the structure of your application, there may be other places where you want to COMMIT a transaction. That's what the COMMIT statement is for. One thing to keep in mind is that the frequency of COMMITs will affect performance. The more COMMITs you do, the slower your application will be. For interactive processes, you can probably ignore the performance issue, but for batch-mode operations, COMMITing too often can really slow things down.

Another issue to be aware of is that APPXIO files do not support transaction processing. If you ROLLBACK a change to an RDBMS-hosted file, any changes made to APPXIO will not be rolled back. Related to this is the issue of visibility. Changes made to an RDBMS-hosted file are invisible to other users until they are committed. Changes made to an APPXIO-hosted file are visible immediately.

Related PDFs

COMMIT MODE

Related Statements

ROLLBACK, SAVEPNT

Example

In the following example, if the flag indicates it is OK to commit, the COMMIT takes place and processing continues. Otherwise, changes made since the savepoint designated as TRX POINT 1 are discarded and the program branches to an applicable routine. 

        SAVEPNT  TRX POINT 1
        *
              <perform RDBMS processing>
        *
        IF       TAR WORK OK TO COMMIT          NE Y
  T     ROLLBACK TRX POINT 1
  T     GOTO    :TRX POINT 1 STATUS
        COMMIT

Application Design Manual                                         "Powered by Appx Software"

631

©2006 By APPX Software, Inc. All Rights Reserved